Cross-Origin Resource Sharing (CORS): Konfiguration och bästa praxis för säkerhet

Inom webbutveckling är säkerhet av yttersta vikt. En kritisk aspekt av webbsäkerhet är att hantera hur webbsidor från ett ursprung kan komma åt resurser från ett annat ursprung. Det är här Cross-Origin Resource Sharing (CORS) kommer in i bilden. CORS är en säkerhetsfunktion i webbläsare som begränsar webbsidor från att göra förfrågningar till en annan domän än den som serverade webbsidan. Denna mekanism finns för att förhindra att skadliga webbplatser kommer åt känslig data. Den här artikeln ger en omfattande guide till CORS, som täcker dess konfiguration, säkerhetsimplikationer och bästa praxis.

Förstå Same-Origin Policy

CORS bygger på grunden av Same-Origin Policy (samma ursprungsprincip), en grundläggande säkerhetsmekanism som implementeras av webbläsare. Samma ursprungsprincip begränsar webbsidor från att göra förfrågningar till en annan domän än den som serverade webbsidan. Två URL:er anses ha samma ursprung om de har samma protokoll (t.ex. HTTP eller HTTPS), värd (t.ex. example.com) och port (t.ex. 80 eller 443). Till exempel:

• http://example.com och http://example.com/path har samma ursprung.
• http://example.com och https://example.com har olika ursprung (olika protokoll).
• http://example.com och http://www.example.com har olika ursprung (olika värdar).
• http://example.com:80 och http://example.com:8080 har olika ursprung (olika portar).

Samma ursprungsprincip är utformad för att förhindra Cross-Site Scripting (XSS)-attacker, där en skadlig webbplats injicerar skript i en betrodd webbplats för att stjäla användardata eller utföra obehöriga åtgärder. Utan samma ursprungsprincip skulle en skadlig webbplats potentiellt kunna komma åt dina bankkontouppgifter om du var inloggad på din internetbank i en annan flik.

Vad är Cross-Origin Resource Sharing (CORS)?

Även om samma ursprungsprincip är avgörande för säkerheten, kan den också vara restriktiv i legitima scenarier där webbplatser behöver komma åt resurser från olika ursprung. Till exempel kan en webbapplikation som hostas på example.com behöva hämta data från ett API som hostas på api.example.net. CORS tillhandahåller en mekanism för att kringgå samma ursprungsprincip på ett kontrollerat sätt, vilket gör att webbsidor kan göra förfrågningar mellan olika ursprung när servern uttryckligen godkänt det.

CORS fungerar genom att lägga till HTTP-headers i svaret från servern, vilket indikerar vilka ursprung som tillåts komma åt resursen. Webbläsaren kontrollerar sedan dessa headers och blockerar förfrågan om ursprunget för webbsidan som gör förfrågan inte är tillåtet.

Hur CORS fungerar: HTTP-headers

CORS förlitar sig på specifika HTTP-headers för att underlätta förfrågningar mellan olika ursprung. Här är de viktigaste headers som är involverade:

1. Origin (Request Header)

Origin-headern skickas av webbläsaren i förfrågningar mellan olika ursprung. Den indikerar ursprunget (protokoll, värd och port) för webbsidan som gör förfrågan. Till exempel:

            Origin: http://example.com
            

              
                Copy
              
            
          

2. Access-Control-Allow-Origin (Response Header)

Access-Control-Allow-Origin-headern är den viktigaste headern i CORS. Den specificerar vilka ursprung som tillåts komma åt resursen. Den kan ha ett av följande värden:

• Ett specifikt ursprung: Till exempel, Access-Control-Allow-Origin: http://example.com tillåter endast förfrågningar från http://example.com.
• * (jokertecken): Access-Control-Allow-Origin: * tillåter förfrågningar från vilket ursprung som helst. Detta bör användas med försiktighet, eftersom det i praktiken inaktiverar samma ursprungsprincip för den resursen.

Exempel:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

3. Access-Control-Allow-Methods (Response Header)

Access-Control-Allow-Methods-headern specificerar de HTTP-metoder (t.ex. GET, POST, PUT, DELETE) som är tillåtna i förfrågan mellan olika ursprung. Detta krävs för preflight-förfrågningar (förklaras nedan).

Exempel:

            Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
            

              
                Copy
              
            
          

4. Access-Control-Allow-Headers (Response Header)

Access-Control-Allow-Headers-headern specificerar de HTTP-headers som är tillåtna i förfrågan mellan olika ursprung. Detta krävs också för preflight-förfrågningar.

Exempel:

            Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
            

              
                Copy
              
            
          

5. Access-Control-Allow-Credentials (Response Header)

Access-Control-Allow-Credentials-headern specificerar om webbläsaren ska inkludera autentiseringsuppgifter (t.ex. cookies, authorization-headers) i förfrågan mellan olika ursprung. Den kan ha ett av två värden: true eller false. Om true är satt, kan Access-Control-Allow-Origin-headern inte sättas till *. Den måste vara ett specifikt ursprung.

Exempel:

            Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

6. Access-Control-Max-Age (Response Header)

Access-Control-Max-Age-headern specificerar antalet sekunder som webbläsaren kan cacha resultaten från preflight-förfrågan. Detta kan förbättra prestandan genom att minska antalet preflight-förfrågningar.

Exempel:

            Access-Control-Max-Age: 3600
            

              
                Copy
              
            
          

Enkla förfrågningar vs. Preflight-förfrågningar

CORS skiljer mellan två typer av förfrågningar mellan olika ursprung: enkla förfrågningar och preflight-förfrågningar.

Enkla förfrågningar

En enkel förfrågan är en förfrågan som uppfyller följande kriterier:

• Metoden är GET, HEAD, eller POST.
• Om metoden är POST, är Content-Type-headern en av följande: application/x-www-form-urlencoded, multipart/form-data, eller text/plain.
• Förfrågan sätter inga anpassade headers (förutom de som automatiskt sätts av webbläsaren).

För enkla förfrågningar skickar webbläsaren förfrågan direkt till servern. Servern svarar sedan med lämpliga CORS-headers. Om ursprunget är tillåtet, bearbetar webbläsaren svaret. Annars blockerar webbläsaren svaret och kastar ett fel.

Preflight-förfrågningar

En preflight-förfrågan skickas av webbläsaren innan den faktiska förfrågan mellan olika ursprung görs om förfrågan inte uppfyller kriterierna för en enkel förfrågan. Detta händer vanligtvis när förfrågan använder en annan metod än GET, HEAD, eller POST, eller när förfrågan sätter anpassade headers.

Preflight-förfrågan är en OPTIONS-förfrågan som inkluderar följande headers:

• Origin: Ursprunget för webbsidan som gör förfrågan.
• Access-Control-Request-Method: HTTP-metoden som kommer att användas i den faktiska förfrågan.
• Access-Control-Request-Headers: En kommaseparerad lista över de anpassade headers som kommer att användas i den faktiska förfrågan.

Servern svarar sedan med följande headers:

• Access-Control-Allow-Origin: Ursprunget som tillåts komma åt resursen.
• Access-Control-Allow-Methods: De HTTP-metoder som är tillåtna i förfrågan mellan olika ursprung.
• Access-Control-Allow-Headers: De HTTP-headers som är tillåtna i förfrågan mellan olika ursprung.
• Access-Control-Max-Age: Antalet sekunder som webbläsaren kan cacha resultaten från preflight-förfrågan.

Om servern svarar med lämpliga CORS-headers, fortsätter webbläsaren med den faktiska förfrågan mellan olika ursprung. Annars blockerar webbläsaren förfrågan och kastar ett fel.

Exempel på CORS-konfiguration

Implementeringen av CORS varierar beroende på den server-side-teknik du använder. Här är några exempel för vanliga server-side-språk och ramverk:

Node.js med Express

Att använda cors-mellanprogrammet är ett vanligt sätt att konfigurera CORS i Node.js med Express:

            const express = require('express');
const cors = require('cors');
const app = express();

// Aktivera CORS för alla ursprung
app.use(cors());

// Aktivera CORS för ett specifikt ursprung
// app.use(cors({ origin: 'http://example.com' }));

// Aktivera CORS med alternativ
// app.use(cors({
//   origin: ['http://example.com', 'http://localhost:3000'],
//   methods: ['GET', 'POST', 'PUT', 'DELETE'],
//   allowedHeaders: ['Content-Type', 'Authorization'],
//   credentials: true
// }));

app.get('/api/data', (req, res) => {
  res.json({ message: 'Hello from the API!' });
});

app.listen(3001, () => {
  console.log('Server listening on port 3001');
});

            

              
                Copy
              
            
          

Python med Flask

Du kan använda Flask-CORS-tillägget för att konfigurera CORS i Flask:

            from flask import Flask
from flask_cors import CORS

app = Flask(__name__)

# Aktivera CORS för alla ursprung
CORS(app)

# Aktivera CORS för specifika ursprung
# CORS(app, origins=['http://example.com', 'http://localhost:3000'])

@app.route('/api/data')
def get_data():
    return {'message': 'Hello from the API!'}

if __name__ == '__main__':
    app.run(port=3001)

            

              
                Copy
              
            
          

Java med Spring Boot

Spring Boot erbjuder flera sätt att konfigurera CORS. En metod är att använda @CrossOrigin-annoteringen:

            import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@CrossOrigin(origins = "http://example.com") // Specifikt ursprung
public class ApiController {

    @GetMapping("/api/data")
    public String getData() {
        return "Hello from the API!";
    }
}

// Global CORS-konfiguration (med WebMvcConfigurer):

// @Configuration
// public class CorsConfig implements WebMvcConfigurer {

//     @Override
//     public void addCorsMappings(CorsRegistry registry) {
//         registry.addMapping("/**")
//                 .allowedOrigins("http://example.com", "http://localhost:3000")
//                 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
//                 .allowedHeaders("Content-Type", "Authorization")
//                 .allowCredentials(true)
//                 .maxAge(3600);
//     }
// }

            

              
                Copy
              
            
          

PHP

I PHP kan du sätta CORS-headers direkt i ditt skript:

            <?php
header("Access-Control-Allow-Origin: http://example.com");
header("Content-Type: application/json");

$data = array("message" => "Hello from the API!");
echo json_encode($data);
?>

            

              
                Copy
              
            
          

Säkerhetsaspekter med CORS

Även om CORS möjliggör förfrågningar mellan olika ursprung är det avgörande att förstå säkerhetsimplikationerna och implementera det korrekt för att undvika sårbarheter.

1. Undvik att använda Access-Control-Allow-Origin: * i produktion

Att använda jokertecknet * i Access-Control-Allow-Origin-headern tillåter förfrågningar från vilket ursprung som helst, vilket i praktiken inaktiverar samma ursprungsprincip för den resursen. Detta kan exponera ditt API för skadliga webbplatser som potentiellt kan stjäla användardata eller utföra obehöriga åtgärder. Ange istället de exakta ursprung som tillåts komma åt resursen. Till exempel, om din webbapplikation hostas på example.com och behöver komma åt ett API som hostas på api.example.com, sätt headern till Access-Control-Allow-Origin: http://example.com.

Globalt exempel: Föreställ dig ett API för en finansiell tjänst som sätter Access-Control-Allow-Origin: *. En skadlig webbplats skulle då kunna göra förfrågningar till detta API på uppdrag av en inloggad användare, och potentiellt överföra pengar utan användarens vetskap.

2. Validera Origin-headern på servern

Även om du specificerar en lista över tillåtna ursprung är det viktigt att validera Origin-headern på servern för att förhindra att angripare förfalskar ursprunget. En angripare skulle potentiellt kunna skicka en förfrågan med en förfalskad Origin-header för att kringgå CORS-kontrollerna. För att mildra detta, jämför Origin-headern med en lista över betrodda ursprung på serversidan. Om ursprunget inte finns i listan, avvisa förfrågan.

Globalt exempel: Tänk dig en e-handelsplattform. En angripare skulle kunna försöka efterlikna en legitim butiks Origin för att komma åt känslig kunddata från e-handelsplattformens API.

3. Var försiktig med Access-Control-Allow-Credentials: true

Om du sätter Access-Control-Allow-Credentials: true, kan Access-Control-Allow-Origin-headern inte sättas till *. Den måste vara ett specifikt ursprung. Detta beror på att tillåtelse av autentiseringsuppgifter från vilket ursprung som helst kan skapa en säkerhetsrisk, eftersom det kan tillåta skadliga webbplatser att komma åt användardata om de kan lura en användare att besöka deras webbplats medan användaren också är inloggad på målwebbplatsen. Denna inställning är viktig när man hanterar cookies eller authorization-headers.

Globalt exempel: En social medieplattform som tillåter förfrågningar mellan olika ursprung med autentiseringsuppgifter kräver noggrann hantering för att förhindra obehörig åtkomst till användarkonton.

4. Konfigurera Access-Control-Allow-Methods och Access-Control-Allow-Headers korrekt

Tillåt endast de HTTP-metoder och headers som är nödvändiga för förfrågningarna mellan olika ursprung. Om du bara behöver tillåta GET- och POST-förfrågningar, tillåt inte PUT, DELETE, eller andra metoder. På samma sätt, tillåt endast de specifika headers som din applikation behöver. Alltför tillåtande konfigurationer kan öka risken för attacker.

Globalt exempel: Ett CRM-system bör endast exponera de nödvändiga API-slutpunkterna och headers för auktoriserade tredjepartsintegrationer, vilket minimerar attackytan.

5. Använd HTTPS för säker kommunikation

Använd alltid HTTPS för säker kommunikation mellan webbläsaren och servern. HTTPS krypterar data som överförs mellan webbläsaren och servern, vilket förhindrar avlyssning och man-in-the-middle-attacker. Att använda HTTP kan exponera känslig data för angripare, även om CORS är korrekt konfigurerat.

Globalt exempel: Sjukvårdsapplikationer måste använda HTTPS för att skydda patientdata som överförs mellan olika ursprung.

6. Content Security Policy (CSP)

Även om det inte är direkt relaterat till CORS, är Content Security Policy (CSP) en annan viktig säkerhetsmekanism som kan hjälpa till att förhindra XSS-attacker. CSP låter dig definiera en vitlista över källor från vilka webbläsaren får ladda resurser. Detta kan hjälpa till att förhindra angripare från att injicera skadliga skript i din webbplats, även om de lyckas kringgå andra säkerhetsåtgärder.

Globalt exempel: Finansiella institutioner använder ofta strikta CSP-policyer för att begränsa källorna till innehåll som laddas på deras internetbanksportaler, vilket minskar risken för XSS-attacker.

Vanliga CORS-problem och felsökning

CORS-fel kan vara frustrerande att felsöka. Här är några vanliga problem och hur man felsöker dem:

1. "No 'Access-Control-Allow-Origin' header is present on the requested resource."

Detta är det vanligaste CORS-felet. Det indikerar att servern inte returnerar Access-Control-Allow-Origin-headern i sitt svar. Se till att servern är konfigurerad att skicka korrekta CORS-headers för ursprunget för webbsidan som gör förfrågan. Dubbelkolla din server-side-kod och konfigurationsfiler.

2. "Response to preflight request doesn't pass access control check: It does not have HTTP ok status."

Detta fel indikerar att preflight-förfrågan misslyckades. Detta kan hända om servern inte svarar på OPTIONS-förfrågningar eller om servern returnerar en felstatuskod (t.ex. 404, 500) som svar på preflight-förfrågan. Se till att din server är konfigurerad för att hantera OPTIONS-förfrågningar och att den returnerar en 200 OK-statuskod.

3. "Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'."

Detta fel inträffar när du försöker skicka autentiseringsuppgifter (t.ex. cookies) i en förfrågan mellan olika ursprung och Access-Control-Allow-Origin-headern är satt till *. Som nämnts tidigare kan du inte använda jokertecknet * när du skickar autentiseringsuppgifter. Du måste specificera det exakta ursprunget som tillåts komma åt resursen.

4. Webbläsarcache

Webbläsare kan cacha CORS-svar, vilket kan leda till oväntat beteende om CORS-konfigurationen ändras. För att förhindra cacheproblem, sätt Cache-Control-headern i svaret till no-cache, no-store, eller max-age=0. Du kan också använda Access-Control-Max-Age-headern för att kontrollera hur länge webbläsaren cachar resultaten från preflight-förfrågan.

Alternativ till CORS

Även om CORS är standardmetoden för att möjliggöra förfrågningar mellan olika ursprung, finns det några alternativ som du kan överväga i vissa scenarier:

1. JSON med Padding (JSONP)

JSONP är en teknik som använder <script>-taggen för att kringgå samma ursprungsprincip. JSONP fungerar genom att slå in JSON-data i ett JavaScript-funktionsanrop. Webbläsaren exekverar sedan JavaScript-funktionen och skickar JSON-datan som ett argument. JSONP är enklare att implementera än CORS, men det har vissa begränsningar. Det stöder endast GET-förfrågningar, och det är mindre säkert än CORS.

2. Omvänd proxy

En omvänd proxy är en server som sitter framför din API-server och vidarebefordrar förfrågningar till den. Den omvända proxyn kan konfigureras för att lägga till nödvändiga CORS-headers i svaret, vilket effektivt döljer förfrågningarna mellan olika ursprung från webbläsaren. Detta tillvägagångssätt kan vara användbart om du inte har kontroll över API-servern eller om du vill förenkla CORS-konfigurationen.

Slutsats

Cross-Origin Resource Sharing (CORS) är en avgörande säkerhetsmekanism som gör att webbsidor kan komma åt resurser från olika ursprung på ett kontrollerat sätt. Att förstå hur CORS fungerar och implementera det korrekt är avgörande för att bygga säkra och pålitliga webbapplikationer. Genom att följa de bästa praxis som beskrivs i denna artikel kan du effektivt hantera CORS och skydda dina API:er från obehörig åtkomst.

Kom ihåg att alltid prioritera säkerhet när du konfigurerar CORS. Undvik att använda jokertecken, validera Origin-headern och använd HTTPS för säker kommunikation. Genom att vidta dessa försiktighetsåtgärder kan du säkerställa att dina webbapplikationer är skyddade mot cross-site-attacker.

Denna omfattande guide ger en solid grund för att förstå CORS. Se alltid till att konsultera den officiella dokumentationen för din specifika server-side-teknik för den mest uppdaterade informationen och bästa praxis. Håll dig informerad om nya säkerhetshot och anpassa din CORS-konfiguration därefter.